ARGUMENTS: Arg [a] Tablespace Number (TSN) Arg [b] Decimal Relative Data Block Address (RDBA)
In 12c it includes Multitenant information: Arg [a] 0 if Multitenant is not enabled or 0 if there is not Root CDB session, 1 ROOT PDBID, otherwise PDBID top session Arg [b] PDBID Arg [c] Tablespace Number (TSN) Arg [d] Decimal Relative Data Block Address (RDBA)
因为 TESTDB 是一套 11GR2 的库，所以只需要看对应版本的 ARGUMENTS 即可：
1 2 3
ARGUMENTS: Arg [a] Tablespace Number (TSN) Arg [b] Decimal Relative Data Block Address (RDBA)
SUGGESTIONS: 1. If the Arg [b] or [d] in 12c (the RDBA) is 0 (zero), then this could be caused by fake indexes. The following query will list fake indexes:
select do.owner,do.object_name, do.object_type,sysind.flags from dba_objects do, sys.ind$ sysind where do.object_id = sysind.obj# and bitand(sysind.flags,4096)=4096;
If the above query returns any rows, check the objects involved and consider dropping them as they can cause this error.
or it could be the case described in the next article when allocating a block for a LOB segment in a DML: Note 1608861.1 ORA-00600 [25027] [x] [0]
2. Run analyze table validate structure on the table referenced in the Current SQL statement in the related trace file.
If the Known Issues section below does not helpin terms of identifying a solution, please submit the trace files and alert.log to Oracle Support Services for further analysis.
这里第一条的 b 值为 0，看起来与我们的情况有些相符，大概意思有可能是由虚假索引导致的，建议检查是否存在虚假索引：
1 2 3 4 5 6
SQL>select do.owner,do.object_name, do.object_type,sysind.flags from dba_objects do, sys.ind$ sysind where do.object_id = sysind.obj# and bitand(sysind.flags,4096)=4096;
SQL>desc LUCIFER.CUS_LUCIFER_UPLOAD_BASE Name Null? Type ----------------------------------------- -------- ---------------------------- UPDATE_TIME DATE TERMINAL_ID NUMBER PART_ID NUMBER RESULT VARCHAR2(32) SUM_COUNT NUMBER SUCC_COUNT NUMBER FAIL_COUNT NUMBER WORK_ORDER VARCHAR2(32) UPLOAD_TIME DATE KEYID VARCHAR2(64) FTP_PATH VARCHAR2(1024) FTP_TYPE NUMBER UPDATE_EMPNO VARCHAR2(64) MACHINE_ID NUMBER RECID VARCHAR2(256) CREATE_TIME DATE CREATE_DATE NUMBER
-- 查看 a 值 8 对应的表空间数据文件，对应的都是索引表空间 SQL>select t.ts#, t.name tablespace_name, f.file#, f.name file_name from v$tablespace t, v$datafile f where t.ts#=f.ts# and t.ts#=8;
-- 查看表所在的数据文件 select file_name from dba_tables t1, dba_data_files t2 where t1.tablespace_name=t2.tablespace_name and t1.owner='LUCIFER'and t1.table_name='CUS_LUCIFER_UPLOAD_BASE';
alter table LUCIFER.CUS_LUCIFER_UPLOAD_BASE rename to CUS_LUCIFER_UPLOAD_BASE_BAK; create table LUCIFER.CUS_LUCIFER_UPLOAD_BASE tablespace lucifer asselect*from LUCIFER.CUS_LUCIFER_UPLOAD_BASE_BAK; create index LUCIFER.IDX_LUCIFER_ATEUPLOAD_BASE_SN on CUS_LUCIFER_UPLOAD_BASE (TERMINAL_ID) tablespace LUCIFERIDX parallel 32; alter index LUCIFER.IDX_LUCIFER_ATEUPLOAD_BASE_SN noparallel;
Ref: Physical and Logical Block Corruptions. All you wanted to know about it. ( Doc ID 840978.1 )
Logical Block Corruptions
This is when block contains a valid checksum and the structure below the beginning of the block is corrupt (Block content is corrupt). It may cause different ORA-600 errors. The detailed corruption description for Logical Corruptions are not normally printed in the alert.log. DBVerify will report what is logically corrupted in the block.
Ref: Handling Oracle Block Corruptions ( Doc ID 28814.1 )
Overview of Steps to handle a Corruption
There are many possible causes of a block corruption including: ・Bad IO hardware / firmware ・OS problems ・Oracle problems ・Recovering through "UNRECOVERABLE" or "NOLOGGING" database actions (inwhichcase ORA-1578 is expected behaviour - see below)
比如，已知的和存储相关的现象，烦请参考下面的技术文档。
Ref: Database Corruption due to stale/old blocks after EMC SRDF/A DR switchover - ORA-600 [25027] ORA-600 [kdsgrp1] ORA-8103 ORA-1410 ( Doc ID 1675764.1 )
